\section{Conclusion}

Android has the big advantage of the Java SE language, that is either powerful and simple. But Android OS loose 
some of the Java main features. Not only it binds the application exclusively on Andorid paltforms, even with programs 
that don't use the OS API (for example threads, commons in many of the Java programs, are not supported by Android) 
but it also strongly influences the application by this API version. This seem normal, but some very important API was 
added only in the latest versions.
In fact earlier version of Android OS support a very small set of API and the real problem is that most of the terminals 
have not received the updates from they manufacters to update to a recent version of the system.

As described in the issues section we can not use the API for the Wifi managing as it were introduced in the version 1.6 
and the terminal that we are using with the last official update arrive only at 1.5. And the last update was released more 
than six months ago, and the lastest version of Android API has overcame the version 2. This should make understand how some 
terminals are bad supported by their manufacters.

Also the IDE integration of Android Emulator is anything but perfect. The emulator is incredibly slow, many times the IDE fails 
to connect to the emulator (with the result that the application dosn't start), and this probability dramatically reduce when the 
developer try to lunch the application in debug mode.
Another problem is the lack of features support by the emulator, for example it dosn't support the bluetooth and wifi connection, 
and this is a big limit for the applications test. And it isn't possibile to open more istances of the emulator on the same pc, and
this limit the tests of a multiclient configuration.

In conclusion Android has great potentiality, but either the lack of support from the terminals manufacters and the many limits of the 
emulator limit it consistently.


\subsection{Possible works and future enhancements}

Let's see now what could be some functional and not improvements for the WiFi Take-away application.

\subsubsection{Feature enhancements}
\begin{itemize}
\item Editing and deletion of an order still not ready to be withdrawed.
\item Sending an SMS to the user when the order is ready to be withdrawed.
\item Automatic managment of the payment, for example saving the detail of a credit card or 
paypal account on the terminal, and this information could be sended (crypted) to the server. 

Another possibility could be the creation of an account on the server with this information inside 
and the association user-account could be done with the mac address of the terminal using it as "username", 
but for security is better to use a password.
\end{itemize}

\subsubsection{Other enhancements}
\begin{itemize}
\item Improvement of the GUI to make it more user friendly, with the possibility to display a picture of every
item that could be ordered and the possibility to set the ordered quantity of an item without opening more e more
times a contextual menu, but using the keyboard of the terminal (or using a virtual keyboard if the terminal has only
the touch screen).
\item Estimate the possibility of the implementation of VoiceXML standard to make more simple and fast some phases of
the order.
\item Add the possibility to influence the calculation of the time to wait for an order, adjusting it when (for example)
there are delays in the kitchen or in the WLAN.
\end{itemize}

\subsection{Roles \& Activity}
\paragraph{Michele Bortolato}
\begin{itemize}
 \item Analysis requirement;
 \item Server development;
 \item Server communication test;
 \item Documentation.
\end{itemize}

\paragraph{Marco Orlandin}
\begin{itemize}
 \item Analysis requirements;
 \item Client-side: logical view, development and test;
 \item Documentation
\end{itemize}
 
\paragraph{Marco Secchiero}
\begin{itemize}
 \item Analysis requirements;
 \item Client-side: GUI design, development and test;
 \item Documentation
\end{itemize}

